{\rtf1\mac\ansicpg10000\cocoartf824\cocoasubrtf410
{\fonttbl\f0\fswiss\fcharset77 Helvetica-Bold;\f1\fswiss\fcharset77 Helvetica;}
{\colortbl;\red255\green255\blue255;\red255\green0\blue14;}
\margl1440\margr1440\vieww9000\viewh8400\viewkind0
\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\qc\pardirnatural

\f0\b\fs36 \cf2 WARNING: This is an alpha build. Expect it to crash on you, eat your dog and explode your car!
\f1\b0\fs24 \cf0 \
\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\ql\qnatural\pardirnatural
\cf0 \
Eventually, a real ReadMe will be written so don't be worried :)\
\
So, UITestingKit implements test cases similar to the way SenTestingKit does. That is, it looks for all subclasses of DPTestCase, instantiate them, and invokes all methods that begin with 'test'. Simple right? Sure, but there is a bit more. Unlike SenTestingKit, UITestingKit also looks at the return values of your test methods, and accepts these types: void, id, Class, BOOL and DPTestStatus (see DPTestStatistics.h). Based on the return type UITestingKit knows how to handle your test.\
\
Firstly, UITestingKit decides whether a test is synchronized or not. Synchronized tests know their result (success/failure) when the method returns, while async tests are being put in a pending state after their method executed. A test case can not complete until all of its tests have been completed. void return type is always considered to be async while BOOL is always synced. id and Class are a special case, and this is where the fun begins.\
\
UITestingKit allows you not only to make UI/unit tests, but also to measure the speed of tests in order to get some feedback about your algorithm/implementation. In order to accomplish this it breaks the action of the test from its verification. When UITestingKit sees a method with an object return type (id or Class), it first looks for a matching verification method. Verification methods begin with 'verifyTest' and end with the test name, so if we have a -testFunctionA test, its verification method will be -verifyTestFunctionA: (note the colon at the end). If a verification method is found, it is then invoked with the return value of the test and returns the result of it (success/failure/pending). If no verification method is found, -verifyResult:ofTest: is invoked, and since the default implementation returns a pending state for all tests, object returning tests are considered async by default. You can override -verifyResult:ofTest: in order to provide a generic verification for similar methods. Go crazy with this and do what works for you :)\
\
OK, so we got ourself an async test that now just sits and waits for a completion status (success or failure). When you know this status, just call -setStatus:forPendingTest: and UITestingKit will handle the rest.\
\
Roughly speaking, you need to do nothing different for UI testing. For your convenient, UITestingKit provides a small ObjC wrapper around the accessibility API that you can use to test your UI (DPUIElement and DPAccessibilityNotificationCenter). The headers together with AppKit's headers and the docs on Apple's site should explain everything you need. After you'll read these, you'll probably understand finding the UI element(s) you want to test is not going to be simple, and for that we also provide DPNameServer and DPUIElement's -childNamed: and -anyChildNamed: methods. Either link your app to UITestingKit or compile DPNameServer.h/m directly to it, and use this mechanism to name your UI and find it later.\
\
All of this fits together in tests modules. Tests modules are simply cocoa bundles with a .testsModule extension that contain DPTestCase subclasses (and anything else you want). When the TestsRunner is being fed with module(s) it executes all tests in them in a random order and without waiting for pending tests to complete. This means *ALL* tests are first being executed and only then it sits waiting for pending tests to finish so never count on anything being ordered. The tests runner is located in /Library/Frameworks/UITestingKit.framework/TestsRunner. Call it with a -h flag to see what it can do for you.\
\
Other than that, UITestingKit comes with 3 Xcode templates: a project templete, a target template and a file template. The latter is used to create test cases while the first two for tests modules. There are also some examples being installed to /Developer/Documentation/UITestingKit/Examples that are probably worth looking at.}